IGNITE-28819 Thin client implementation extraction#13306
Open
nizhikov wants to merge 110 commits into
Open
Conversation
Create empty modules/thin-client/impl (ignite-thin-client-impl) for the
thin client implementation extraction. It depends only on ignite-commons,
ignite-binary-api and ignite-thin-client-api (no ignite-core dependency).
Wire it into the reactor (root pom.xml), the BOM dependency management,
and ignite-core (compile dependency + maven-shade include) so the module's
classes are bundled back into ignite-core.jar for binary compatibility,
mirroring ignite-thin-client-api.
Exclude ignite-thin-client-impl from the assembly dependency sets
(dependencies-apache-ignite{,-lgpl,-slim}.xml) as done for
ignite-thin-client-api, since the classes ship inside ignite-core.jar.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of the first leaf class of the thin client implementation. ProtocolVersion has no dependencies on ignite-core internals and is referenced only from within the thin client package, so it moves cleanly. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. BinaryNameMapperMode has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientCacheEntry has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientConnection has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…impl Pure relocation (no code change) of a leaf class of the thin client implementation. ClientConnectionStateHandler has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientJCacheAdapter has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ent-impl Pure relocation (no code change) of a leaf class of the thin client implementation. ClientJCacheEntryListenerAdapter has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientMessageDecoder has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientMessageHandler has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientNotificationType has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientProtocolError has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…impl Pure relocation (no code change) of a leaf class of the thin client implementation. ClientRetryPolicyContextImpl has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. IgniteClientFutureImpl has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. NotificationListener has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ProtocolVersionFeature has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. QueryPager has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientConnectionMultiplexer has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ient-impl Pure relocation (no code change) of a leaf class of the thin client implementation. ClientInternalBinaryConfiguration has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientOperation has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientQueryCursor has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. FieldsQueryPager has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ProtocolContext has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client implementation. ClientFieldsQueryCursor has no ignite-core internal dependencies and is referenced only from within the thin client package. Its class still ships in ignite-core.jar via the shade of ignite-thin-client-impl. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ClientServiceDescriptorImpl's only ignite-core dependency was the import of
org.apache.ignite.services.Service, used solely in a javadoc {@link}. Per the
move convention, the javadoc-only import is removed (the {@link Service} text
remains; doclint is disabled so it does not fail the build), leaving the class
free of ignite-core internals. Relocated to ignite-thin-client-impl; its class
still ships in ignite-core.jar via the shade.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocate the ClusterNodeFunc utility class from ignite-core to ignite-commons so it is available to modules that must not depend on ignite-core (the thin client implementation being extracted uses ClusterNodeFunc.eqNodes). The class keeps its package org.apache.ignite.internal.util.lang, so all existing ignite-core call sites are unaffected. ClusterNodeFunc references four node-id predicates that lived in ignite-core (ContainsNodeIdsPredicate, EqualsClusterNodeIdPredicate, HasEqualIdPredicate, HasNotEqualIdPredicate); they depend only on ignite-commons classes (ClusterNode, S, IgnitePredicate) and are moved alongside it (keeping their gridfunc package). EqualsUuidPredicate already lives in ignite-commons. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ClientClusterNodeImpl's only ignite-core dependency was the static import of ClusterNodeFunc.eqNodes, now resident in ignite-commons. All its other dependencies (ClusterNode, ClusterMetrics, S, IgniteProductVersion) already live in ignite-commons, so this is a pure relocation with no code change. The class still ships in ignite-core.jar via the shade. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocate the SSL context factory classes (SslContextFactory, AbstractSslContextFactory, DelegatingSSLContextSpi, SSLContextWrapper, SSLServerSocketFactoryWrapper, SSLSocketFactoryWrapper and package-info) from ignite-core to ignite-commons so they are available to modules that must not depend on ignite-core. The thin client implementation being extracted uses SslContextFactory.DFLT_STORE_TYPE / DFLT_KEY_ALGORITHM. The package org.apache.ignite.ssl is preserved, so all existing call sites (configuration classes, discovery/communication SPIs, etc.) are unaffected. The package's only external dependencies are IgniteException and the A argument-check helper, both already in ignite-commons. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ClientSslUtils's only ignite-core dependencies were the static imports of SslContextFactory.DFLT_STORE_TYPE / DFLT_KEY_ALGORITHM, now resident in ignite-commons. Its other dependencies (SslMode, SslProtocol, ClientConfiguration) already live in ignite-thin-client-api, so this is a pure relocation with no code change. The class still ships in ignite-core.jar via the shade. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocate AffinityTopologyVersion from ignite-core to ignite-commons so it is available to modules that must not depend on ignite-core. The thin client channel abstraction (ClientChannel#serverTopologyVersion) returns it. The class is a self-contained value type whose only external dependency (the S to-string helper) already lives in ignite-commons; its package org.apache.ignite.internal.processors.affinity is preserved so all existing call sites are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocate the self-contained FastSizeDeque (package org.apache.ignite.util.deque) from ignite-core to ignite-commons. It is used by GridSelectorNioSessionImpl in the NIO engine that will move to ignite-nio; it has no ignite-core dependencies of its own. Binary compatibility is preserved via the maven-shade bundling of ignite-commons into ignite-core.jar. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…her to ignite-commons Relocate the GridWorker base class together with the WorkProgressDispatcher interface it implements and the GridWorkerListener it references (all package org.apache.ignite.internal.util.worker) from ignite-core to ignite-commons. These form the worker-thread foundation used by the NIO engine (GridNioServer) that will move to ignite-nio. GridWorker's three U calls (currentTimeMillis/error/warn) are repointed to their ignite-commons CommonUtils equivalents. GridWorkerFuture and GridWorkerPool are not referenced by GridWorker and remain in ignite-core. Binary compatibility is preserved via the maven-shade bundling of ignite-commons into ignite-core.jar. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…mons Move Scope, SpanStatus, SpanType, Span, SpanManager, NoopSpan, SpanTags and MTC to ignite-commons, and add NoopSpanManager (no-op SpanManager). GridNioServer now uses SpanManager/NoopSpanManager instead of Tracing/NoopTracing, removing its dependency on the core tracing manager. NoopTracing extends NoopSpanManager. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…rver from TraceableMessagesTable Add traceName(Message) to SpanManager: GridTracingManager delegates to TraceableMessagesTable.traceName, NoopSpanManager returns null. GridNioServer now calls tracing.traceName(msg) instead of the static TraceableMessagesTable.traceName, removing its last dependency on core tracing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…NioServer uses CommonUtils Move sleep(long), cancel(GridWorker), cancel(Iterable), join(GridWorker, log), join(Iterable, log) and newThread(GridWorker) from IgniteUtils to CommonUtils (commons). IgniteUtils still inherits them via CommonUtils, so existing U.* callers are unaffected. GridNioServer now calls CommonUtils instead of U, removing its dependency on core IgniteUtils. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…nd DFLT_IO_BALANCE_PERIOD to IgniteCommonsSystemProperties; GridNioServer uses IgniteCommonsSystemProperties Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…uration references it (public API constant kept) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ite-commons Introduce ExpectedFailure marker in ignite-commons so GridCompoundFuture can classify benign failures without referencing core exception types. ClusterTopologyCheckedException, IgniteConsistencyViolationException, IgniteTxOptimisticCheckedException and IgniteFutureCancelledCheckedException implement it. Failure-handling behavior is preserved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…LongAdderMetric Capture the byte-count metrics as bound method references (longAdderMetric(...)::add) and the outbound queue size as longAdderMetric(...)::value, removing the direct dependency on LongAdderMetric. No boxing and no per-call allocation, so the hot path is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…stead of MetricRegistryImpl Move metric creation to the GridNioServer call site and pass the queue-size and max-queue-size metrics as bound method references (longAdderMetric(...)::add, maxValueMetric(...)::update). Removes LongAdderMetric, MaxValueMetric and MetricRegistryImpl from the session. increment()/decrement()/add()/update() become accept(1)/accept(-1)/accept(n), preserving behavior. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ry, drop GridNioServer.outboundMessagesQueueSize() The size is read in a single place (TcpCommunicationSpi.getOutboundMessagesQueueSize), which already has the communication metric registry via TcpCommunicationMetricsListener. Expose it there and delegate from the SPI, removing the LongSupplier metric and the read method from GridNioServer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ioServer fields The outbound and max queue-size metrics were rebuilt from the registry on every session creation; since the metric names are constant the registry returns the same instance, so cache them once as final LongConsumer fields in the constructor and pass them to each session. Removes the last reads of the mreg instance field, so the field is dropped (mreg remains only as a constructor parameter and in the Builder). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move metric registration out of GridNioServer into the callers via IgniteUtils helpers: setNioServerMetrics (byte counters + queue-size consumers), registerSslEnabledMetric (SslEnabled gauge) and registerActiveSessionsMetric (ActiveSessionsCount gauge, backed by the new GridNioServer.activeTcpSessionsCount). GridNioServer no longer references the metric registry: the mreg constructor parameter, Builder field and metricRegistry() setter are removed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ry-api and shared types to ignite-commons Move MessageFactory, MessageReader, MessageWriter and MessageSerializer to ignite-binary-api (they reference IgniteUuid/CacheObject/KeyCacheObject which live there). Move the shared MessageType, MessageCollectionItemType, MessageArrayType, MessageCollectionType, MessageMapType enums and GridLongList to ignite-commons, and relocate EMPTY_LONGS from IgniteUtils to CommonUtils (still inherited by IgniteUtils). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add the ignite-binary-api dependency to the ignite-nio module so the communication Message API (MessageFactory/Reader/Writer/Serializer, now in binary-api) is visible to NIO classes that will be moved into this module. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…age via marker interfaces Introduce two marker interfaces in ignite-commons: MessageContainer (a message that wraps another message, implemented by GridIoMessage) and SelfSerializingMessage (a message that serializes itself directly to a ByteBuffer, implemented by ClientMessage). GridNioServer now references the markers instead of the concrete core message classes, removing its last cross-module core dependencies (only same-package nio types remain). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…to IgniteCommonsSystemProperties Relocate the property and its DFLT_NIO_RECOVERY_DESCRIPTOR_RESERVATION_TIMEOUT default to IgniteCommonsSystemProperties; GridNioRecoveryDescriptor uses IgniteCommonsSystemProperties, removing its IgniteSystemProperties dependency. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ADER/writeFully/bytesEqual to CommonUtils Relocate IGNITE_HEADER, writeFully(SocketChannel,ByteBuffer) and bytesEqual(...) from IgniteUtils to CommonUtils (still inherited by IgniteUtils) and repoint the nio package classes from U to CommonUtils, removing their dependency on core's typedef U. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Its only core tie was an @see CIX2 javadoc reference; drop it (F.wrap is inherited from commons GridFunc) and move the class to ignite-commons so the NIO communication clients no longer depend on a core type for it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…n to ignite-commons GridWorkerPool uses CommonUtils.cancel/join (already in commons) instead of U, and the ComputeExecutionRejectedException it throws moves to ignite-commons as well (FQN preserved). Removes GridNioAsyncNotifyFilter's dependency on a core worker-pool type. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…r uses SpanManager Move the self-contained SpanTransport marker interface to ignite-commons and retype GridNioTracerFilter's tracer to SpanManager (serialize/create are SpanManager methods), defaulting to NoopSpanManager. Removes the filter's Tracing/NoopTracing/SpanTransport core dependencies. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…Manager Pass the SpanManager from GridNioServer into the session and resolve trace names through SpanManager.traceName instead of the static TraceableMessagesTable.traceName, removing the session's dependency on the core TraceableMessagesTable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ricRegistryImpl Retype the filter's handshake-duration metric to LongConsumer and the rejected-sessions counter to Runnable; metric creation moves to a new IgniteUtils.sslFilter(...) factory that the four construction sites now call. Removes GridNioSslFilter's dependency on MetricRegistryImpl/HistogramMetricImpl/IntMetricImpl. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…cpCommunicationSpi Type the reader as MessageReader (setBuffer/reset suffice, the DirectMessageReader cast was redundant) and inline the 2-byte direct-type decoding instead of using TcpCommunicationSpi.makeMessageType. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Relocate GridNioServer and the entire org.apache.ignite.internal.util.nio package (39 classes, including the ssl subpackage) from ignite-core to the ignite-nio module, now that the package depends only on ignite-commons, ignite-binary-api and ignite-grid-unsafe. Add the ignite-grid-unsafe dependency to ignite-nio. ignite-core continues to depend on ignite-nio, so all existing references resolve. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ite-thin-client-impl With the NIO package now in ignite-nio, add an ignite-nio dependency to ignite-thin-client-impl and move the last 11 thin-client implementation classes (TcpIgniteClient, TcpClientCache, ReliableChannelImpl, ClientServicesImpl, the continuous-query/listener classes and the client-side gridnioserver multiplexer/connection/parser/listener) out of ignite-core. GridNioClientConnectionMultiplexer builds its SSL filter directly (no metrics) instead of via the core IgniteUtils.sslFilter factory. ignite-core keeps a compile dependency on ignite-thin-client-impl, so Ignition and platform-client references still resolve. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Possible compatibility issues. Please, check rolling upgrade casesThis PR modifies protected classes (with Order annotation). Affected files:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thank you for submitting the pull request to the Apache Ignite.
In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:
The Contribution Checklist
The description explains WHAT and WHY was made instead of HOW.
The following pattern must be used:
IGNITE-XXXX Change summarywhereXXXX- number of JIRA issue.(see the Maintainers list)
the
green visaattached to the JIRA ticket (see tabPR Checkat TC.Bot - Instance 1 or TC.Bot - Instance 2)Notes
If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com #ignite channel.